Wireless router remote firmware upgrade

ABSTRACT

A wireless router receives a firmware update from a remote server, and destructively overwrites router firmware in flash memory in a chunk-wise manner, and then writes a kernel memory before going live with upgraded firmware. Some routers authenticate the firmware image. In some cases, image chunks are re-ordered into an executable order after receipt and before finishing their final arrangement in the flash memory. In some routers, a maximum firmware image size is at least two chunk sizes smaller than the flash memory storage capacity. Some routers remap ROM to RAM memory. Some decompress data from flash into a RAM. Some save text file configuration settings in flash before rebooting. Some detect a user&#39;s inactive billing status and redirect a web browser to a billing activation page.

RELATED APPLICATIONS

The present application claims priority to, and incorporates byreference, U.S. patent application Ser. No. 13/763,351 filed Feb. 8,2013 which is now U.S. Pat. No. 9,558,353, U.S. patent application Ser.No. 13/587,394 filed Aug. 16, 2012 which is now U.S. Pat. No. 8,402,109,U.S. patent application Ser. No. 13/015,053 filed Jan. 27, 2011 which isnow U.S. Pat. No. 8,326,936, and U.S. patent application Ser. No.11/350,905 filed Feb. 8, 2006, which is now U.S. Pat. No. 7,904,518, andU.S. Provisional Patent Application Ser. No. 60/653,163 filed Feb. 15,2005.

BACKGROUND

To aid understanding of the technical context of the innovations claimedherein, several references are discussed below. This discussion is meantto help promote a full and accurate examination of the claims presented.

However, there are also limits on the inferences one can properly drawfrom this discussion. These references were identified with the presentclaims in mind, and the observations made here about the references arelikewise guided by the present claims. One of skill would notnecessarily have combined any of these references or made suchobservations without the benefit of hindsight. The mere fact that two ormore of the references are discussed here is not evidence of amotivation to combine those references at the time of invention withoutusing the present claims as a blueprint.

Moreover, the inclusion of a reference in this discussion is not ablanket acceptance of every statement made in the reference; what thereferences recite is not necessarily correct. Each reference must alsobe considered independently of this discussion to fully understand thereference's teachings, as only a brief space is allotted to any givenreference here and each reference speaks for itself. The referencerecitations noted here are not meant to be a full description, or even acomplete overview or summary, of the teachings of any reference. Otherreferences may also be considered worthy of attention.

Also, a reference may use terms differently than they are used here indescribing the innovations claimed, and two different references may usethe same term differently. Nor is the inclusion of a reference in thisdiscussion evidence that the reference is enabling with regard to aparticular claim, or indeed, with regard to any claim that is presentedhere.

The following discussion of references begins by pointing out somethings that are not present in any of the references. These gaps in thereferences are worthy of attention, but they are merely examples of howthe references could be considered. In particular, it does not followthat something X is present in the references merely because thediscussion did not say that X was missing from the references.

Bearing these guidelines in mind, the reference discussion will nowproceed.

None of these references mention an “executable order” for “chunks” of afirmware image. None recite “re-ordering” or “re-sequencing” firmwareimage chunks that were received in some order other than the executableorder.

With regard to destructively overwriting flash memory chunks, the onlymention of “destructive” in any of these references is in Zimmer(2005/0021968) paragraph [0048] which recites a “non-destructive reset.”

None of these references recite a “wireless router” as a device whosefirmware will be upgraded. Only Georges (2008/0156178) mentions any ofthe “802.11” wireless communication standards, and that is not inconnection with router firmware upgrades because Georges does notmention “routers” at all.

None of these references mention “checking” to see whether the size of afirmware image is at least two chunk sizes smaller than a device's flashmemory storage capacity.

With regard to remapping a ROM memory address to a RAM memory address inthe context of a firmware upgrade, only two of the references mention“remapping” an address in any context, namely, Moore, et at(2006/0047920) and Shamoon, et al. (2004/0107356). However, Moore'sAbstract directs attention at how to “enable one-time or few-timeprogrammable memories to work with existing consumer electronic devices(such as those that work with flash—an erasable, non-volatile memory)without requiring a firmware upgrade . . . .” (emphasis added). Shamoondirects attention to remapping for security. Shamoon [0310] recites“circuitry which remaps some of the available memory space, so that, inunsecure mode, the CPU cannot address secure memory locations.” Shamoon[0312] similarly recites “Some memory space may be rendered off-limitsto general purpose uses, for example by remapping”.

With regard to writing firmware to both flash memory and a volatile RAMdisk, none of these references mention a “RAM disk” or a “RAM drive”.

United States Patent Application Publication No. 2003/0066062 byBrannock, et at recites that a method for updating platform firmware isdisclosed. Brannock further recites that this capability is facilitatedby a standard software abstraction for a firmware storage device, knownas Firmware Volume (FV) that is managed through a Firmware File System(FFS). The FFS enables firmware files to be created, deleted, andupdated individually. The FFS also enables a plurality of firmware filesto be updated atomically by managing file state information via statebits stored in a file header of each firmware file, whereby an atomicchange to a single state bit simultaneously causes the FFS to use anupdated set of firmware files in place of an original set of firmwarefiles.

United States Patent Application Publication No. 2004/0083469 by Chen,et at recites that an update method is used in an optical disk system toupdate firmware information stored in a firmware memory. Chen furtherrecites that the method includes fetching program code and an updateprogram routine from an update source, storing the program code into afirst buffer, storing the update program routine into a second buffer,executing the update program routine stored in the second buffer,writing the program code stored in the first buffer into the firmwarememory to update the firmware information, and changing a value of aprogram counter of the microprocessor such that the microprocessorexecutes the program code stored in the firmware memory at apredetermined location of the program code instead of executing a nextinstruction in the program code located after the current position ofthe program counter, and using the program code as updated firmwareinformation to control the optical disk system.

United States Patent Application Publication No. 2005/0027807 byFengler, et al. recites that systems and methods for facilitatingperipheral device firmware installation are disclosed. Fengler furtherrecites that in one embodiment, a system and a method pertain totransmitting a firmware availability notification, receiving a firmwaredownload request, and transmitting a firmware file to a peripheraldevice for installation on the peripheral device. In another embodiment,a system and a method pertain to receiving a firmware availabilitynotification with a peripheral device, and providing a relatednotification to a user, the related notification being provided by theperipheral device.

United States Patent Application Publication No, 2005/0055595 by Frazer,et al. recites that a system for remotely updating software on at leastone electronic device connected to a network is disclosed. Frazerfurther recites that the electronic devices have a non-volatilerewritable storage unit divided into at least two partitions, one ofwhich will contain core firmware and the other of which will containauxiliary software. When an update is received at the device, theupdated core firmware is written to overwrite the partition in therewritable storage unit that contained the auxiliary software. When thisis completed and verified, the previous version of the core firmwarestored in the storage unit is disabled from execution by the device.Next, the updated auxiliary software is written to overwrite the oldversion of the core firmware. When this write is complete, the devicedetermines a suitable time for it to be rebooted to execute the updatedsoftware. In another embodiment, the present core firmware in the deviceis copied from the partition it is in to the other partition,overwriting the auxiliary software stored there. The new core firmwarereceived to update the device is overwritten into the first partition,the old copied core firmware being present in case of an upgradefailure, and upon a successful update of the first partition, theauxiliary software is written to the second partition, overwriting thecopied old core firmware. In this manner, the position of the corefirmware and auxiliary software within the partitions is preservedduring normal operation of the device.

United States Patent Application Publication No, 2008/0156178 byGeorges, et al, recites that systems and methods for creating,modifying, interacting with and playing music are provided, particularlysystems and methods employing a top-down process, where the user isprovided with a musical composition that may be modified and interactedwith and played and/or stored (for later play). In an unusually longAbstract which is not fully reproduced here, Georges also recites thatthe system preferably is provided in a handheld form factor, and agraphical display is provided to display status information, graphicalrepresentations of musical lanes or components which preferably vary inshape as musical parameters and the Ike are changed for particularinstruments or musical components such as a microphone input or audiosamples. An interactive auto-composition process preferably is utilizedthat employs musical rules and preferably a pseudo random numbergenerator, which may also incorporate randomness introduced by timing ofuser input or the like, the user may then quickly begin creatingdesirable music in accordance with one or a variety of musical styles,with the user modifying the auto-composed (or previously created)musical composition, either for a real time performance and/or forstoring and subsequent playback. The remainder of the Abstract may beread in Georges itself.

United States Patent Application Publication No. 2006/0143475 byHerbert, et al. recites that a method according to one embodiment mayinclude: receiving a first encrypted signal at a server of a computingnetwork, the first encrypted signal comprising firmware encrypted by afirst encryption algorithm having a first complexity level; sending asecond encrypted signal over the computing network to at least onemanaged client in response to the first encrypted signal, the secondencrypted signal comprising the firmware encrypted by a secondencryption algorithm having a second complexity level, wherein saidfirst complexity level is greater than said second complexity level; andupdating existing firmware of the at least one managed client inresponse to receipt of the second signal at the at least one managedclient. Herbert further recites that many alternatives, variations, andmodifications are possible without departing from this embodiment.

United States Patent Application Publication No. 2005/0097542 by Leerecites that a firmware update method is disclosed. First, a tag iswritten to a firmware storage device. Next, first firmware in thefirmware storage device is replaced by second firmware. If the replacingstep is successful, the tag is deleted. Before the execution of thesecond firmware, a verification operation is executed. If the tag is notpresent, the second firmware is executed. If the tag is present, anabnormity processing procedure is executed. The abnormity processingprocedure terminates of execution of the second firmware, reads thirdfirmware via an interface, and replaces the second firmware with thethird firmware.

United States Patent Application Publication No. 2005/0039178 byMarolia, et al. recites that aspects of an invention may be seen in asystem and method for downloading update packages into an electronicdevice communicatively coupled to a carrier network. Marolia furtherrecites that the system may facilitate the update of firmware/softwarein the electronic device, Different protocols may be utilized fordiscovery and download of update packages. Also, different protocols maybe utilized for provisioning and for subsequent downloading of updatepackages.

United States Patent Application Publication No. 2002/0073304 by Marsh,et al. recites that a system and a method that uses a softwareapplication operable under a current firmware/operating systemconfiguration to install a new firmware version without “compromising”the operating system are presented. Marsh further recites that thesoftware application may configure a computer system to install aplurality of software fixes configured to enhance functionality under anew firmware/operating system environment after the firmware has beensuccessfully upgraded. Such functionality enhancements may be associatedwith external peripherals, as well as, input/output circuit cards,processors, and the like. In addition, the software application mayconfigure the computing device to “boot” under the newfirmware/operating system environment upon subsequent systeminitializations. Furthermore, the software application permits thedistribution of firmware upgrades via a network. The capability toinstall firmware remotely permits a system administrator to “push” thenew firmware to a plurality of network coupled computing devices, thusavoiding manual intervention at each device.

United States Patent Application Publication No. 2006/0047920 by Moore,et al. recites that embodiments described therein can be used to enableone-time or few-time programmable memories to work with existingconsumer electronic devices (such as those that work with flash—anerasable, non-volatile memory) without requiring a firmware upgrade,thereby providing backwards compatibility while minimizing user impact.Moore further recites that as such, these embodiments are a viable wayto bridge one-time or few-time programmable memories with existingconsumer electronic devices that have flash card slots. Theseembodiments also allow future consumer electronic devices to be designedwithout updating firmware to include a file system customized for aone-time or few-time programmable memory.

United States Patent Application Publication No. 2003/0236970 by Palmer,et al. recites that in a data processing method and system a massstorage device (DASD) of a data processing system is partitioned toinclude a service partition. Palmer further recites that the servicepartition is typically located on a portion of the DASD beyond thehighest address accessible to the operating system and applicationprograms. The service partition will typically include the currentversions of peripheral device firmware, any BIOS extensions, and devicedrivers. During a system boot, the boot code will invoke a peripheraldevice call that reports the device's firmware version level to comparethe firmware versions of all the peripheral devices against the archivedfirmware versions stored in the service partition. If a mismatch isdetected, the system boot will typically force an update of theperipheral device firmware to the level that is known to be good. Anysuch firmware updates are recorded in a log that is accessible to systemmanagement applications. Any revisions to firmware may be imaged intothe service partition so that the revised version will be incorporatedinto the peripheral device itself during the next subsequent systemboot.

United States Patent Application Publication No, 2004/0015941 by Sekinerecites that an information-processing apparatus includes a nonvolatilememory device configured to store firmware. Sekine further recites thatthe information-processing apparatus has a first unit for issuing aninstruction to make an operating system execute a shutdown process, andto update the firmware, stored in the nonvolatile memory device, afterthe operating system has completed the shutdown process. Theinformation-processing apparatus also has a second unit, responsive tothe instruction to update the firmware, for updating the firmware onlyafter the operating system has completed the shutdown process.

United States Patent Application Publication No, 2004/0107356 byShamoon, et al. recites that a novel method and apparatus for protectionof streamed media content is disclosed. Shamoon further recites that inone aspect, the apparatus includes control means for governance ofcontent streams or content objects, decryption means for decryptingcontent streams or content objects under control of the control means,and feedback means for tracking actual use of content streams or contentobjects. The control means may operate in accordance with rules receivedas part of the streamed content, or through a side-band channel. Therules may specify allowed uses of the content, including whether or notthe content can be copied or transferred, and whether and under whatcircumstances received content may be “checked out” of one device andused in a second device. The rules may also include or specify budgets,and a requirement that audit information be collected and/or transmittedto an external server. In a different aspect, the apparatus may includea media player designed to call plugins to assist in rendering content.A “trust plugin” is disclosed, along with a method of using the trustplugin so that a media player designed for use with unprotected contentmay render protected content without the necessity of requiring anychanges to the media player. In one aspect, the streamed content may bein a number of different formats, including MPEG-4, MP3, and the RMFFformat.

United States Patent Application Publication No. 2005/0021968 by Zimmer,et al. recites that a method for providing a secure firmware update isdisclosed. This Zimmer application further recites that a firstauthentication credential is securely stored on a platform in anencrypted form using a key generated by a secure token, such as atrusted platform module (TPM). Typically, the authentication credentialwill identify a manufacture and the operation will be performed duringmanufacture of the platform. A configuration of the platform is“imprinted” such that an identical configuration is required to accessthe key used to decrypt the first authentication credential by sealingthe key against the platform configuration. During a subsequent firmwareupdate process, a firmware update image containing a secondauthentication credential is received at the platform. If the platformconfiguration is the same as when the key was sealed, the key can beunsealed and used for decrypting the first authentication credential. Apublic key in the first authentication credential can then be used toauthenticate the firmware update image via the second authenticationcredential.

United States Patent Application Publication No. 2005/0289646 by Zimmer,et al. recites disclosure of a method of copying virtual firmware smartcard code from a first secured memory in a system and loading thevirtual firmware smart card code into a second secured memory in thesystem so that the code may be run on a microprocessor to provide smartcard services to the system.

SUMMARY

Various systems/devices and methods for remotely updating routerfirmware are described herein. For example, some embodiments provide amethod for upgrading a wireless router. A flash memory in the wirelessrouter contains a first version of router firmware. The router firmwareincludes instructions to be executed by a processor of the wirelessrouter, and the firmware also includes data. The wireless router sends arequest for a firmware update, the request being sent from the wirelessrouter over a network connection toward a server. The wireless routerreceives over the network connection a response to the request for afirmware update, the response including at least a firmware image for asecond version of router firmware which differs from the first versionof router firmware by reason of containing at least one firmware change(a firmware change being a difference in firmware data and/or adifference in firmware instructions). The firmware image includes aplurality of chunks, each chunk having a size which is no greater than apredetermined chunk size. The wireless router destructively overwritesthe first version of router firmware in the flash memory with the secondversion of router firmware. The destructive overwriting proceeds in achunk-wise manner such that prior to being overwritten by all of thechunks the flash memory contains neither a complete copy of the firstversion nor a complete copy of the second version of the routerfirmware. The wireless router is configured to run whatever version ofrouter firmware is in the router's flash memory after being rebooted.The wireless router reboots, thereby making the firmware change(s) golive.

Some embodiments include writing the flash memory and then writing akernel memory. That is, the wireless router destructively overwrites thefirst version of router firmware in the flash memory with the secondversion of router firmware, and then writes a copy of content of thesecond version of router firmware to a kernel memory in a volatile RAMmemory in the wireless routes before going live with upgraded firmware.

Some embodiments include writing both flash memory and a volatile RAMdisk. That is, the wireless router destructively overwrites the firstversion of router firmware in the flash memory with the second versionof router firmware, and also writes a copy of content of the secondversion of router firmware to a RAM disk hi a volatile RAM memory of therouter.

In some embodiments, the firmware image chunks have at least onepredetermined executable order, namely, an order in which the chunks arearranged in an executable copy of the firmware image. The step ofreceiving a responsive firmware image receives the chunks hi a volatileRAM memory hi the wireless router hi an order which differs from theexecutable order, and the method includes re-ordering the chunks suchthat the step of destructively overwriting flash memory chunks arrangeschunks in the flash memory in the executable order.

In some embodiments, the firmware image has a size and the flash memoryhas a storage capacity. The method includes the wireless router checkingto see whether the size of the firmware image is less than apredetermined maximum firmware image size. The predetermined maximumfirmware image size is at least two chunk sizes smaller than the flashmemory storage capacity.

Some embodiments include the wireless router remapping a ROM memoryaddress in the router to a RAM memory address in the router. Someinclude the wireless router decompressing data held within the flashmemory in the router and copying the data to a RAM-based file system inthe router; some include both steps.

In some embodiments, before going live with upgraded firmware, thewireless router overwrites at least a portion of the flash memory withuser-definable configuration settings from a text file. Then after goinglive with upgraded firmware, the wireless router overwrites the textfile with the configuration settings from the flash memory.

In some embodiments, the response received by the wireless routerincludes an indication that a billing status is inactive, and the methodincludes redirecting a web browser to a billing activation page.

In some embodiments, the firmware image chunks have at least onepredetermined executable order, namely, an order in which the chunks arearranged in an executable copy of the firmware image. The step ofreceiving a responsive firmware image receives the chunks in thewireless router in an order which differs from the executable order. Themethod includes re-ordering the chunks such that the step ofdestructively overwriting flash memory chunks arranges chunks in theflash memory in the executable order. The method also includes writing acopy of the chunks to a kernel memory in the wireless router.

Some embodiments described herein provide a remotely upgradable wirelessrouter. The wireless router includes a processor, volatile RAM memory, anetwork interface card, a wireless link interface, and a flash memory.The volatile RAM memory is in operable communication with the processorand contains a kernel. The kernel includes data and includinginstructions which upon execution by the processor at least partiallycontrol operation of the wireless router. In particular, the kernelcontains a flash memory device driver. The network interface card isconnectable to a TCP/IP network such as the Internet for two-way datacommunication of the wireless router with a remote server. The networkinterface card is also in operable communication with the volatile RAMmemory. The wireless link interface is connectable to a wireless networkfor two-way data communication of the wireless router with a localcomputer, and is also in operable communication with the volatile RAMmemory. The flash memory is in operable communication with the processorby use of the flash memory device driver. The flash memory contains aversion of wireless router firmware, which includes data, also includesand instructions which upon execution by the processor at leastpartially control operation of the wireless link interface.

In some embodiments, the wireless router is further characterized inthat upon execution of at least some of the instructions by theprocessor, the wireless router will do the following: send a request fora firmware update over the network interface card to the remote server,receive over the network interface a wireless router firmware image,write content of the wireless router firmware image to the flash memory,write content of the wireless router firmware image to the kernel memoryafter writing the content to the flash memory, and then reboot, therebypassing control to at least some of the wireless router firmware contentthat was written to the flash memory. In some embodiments, the wirelessrouter does not necessarily send a request for a firmware update, butmay instead receive the firmware update without having first requestedit.

In some embodiments, the flash memory has a storage capacity, and thewireless router firmware image includes a plurality of chunks, eachchunk having a size which is no greater than a predetermined chunk sizeand is less than one-eighth the flash memory storage capacity. Thewireless router upon execution of at least some of the instructions bythe processor destructively overwrites the version of wireless routerfirmware in the flash memory in a chunk-wise manner with chunks of thewireless router firmware image.

In some embodiments, the wireless router firmware image includes aplurality of chunks which have at least one predetermined executableorder, namely, an order in which the chunks are arranged in anexecutable copy of the wireless router firmware image. The wirelessrouter upon execution of at least some of the instructions by theprocessor receives the chunks in the RAM memory in an order whichdiffers from the executable order, and re-orders chunks to arrange thechunks in the flash memory in the executable order.

In some embodiments, the remotely upgradable wireless router includes aROM memory address remapped to a RAM memory address in the router. Insome, the wireless router is joined with a text file containinguser-defined configuration settings, and the flash memory contains acopy of the user-defined configuration settings.

In some embodiments, the wireless router firmware image has a size andthe flash memory has a storage capacity. The wireless router firmwareimage includes a plurality of chunks. Each chunk has a size which is nogreater than a predetermined chunk size and is less than one-eighth theflash memory storage capacity. The size of the wireless router firmwareimage is at least two chunk sizes smaller than the flash memory storagecapacity.

In some embodiments, the wireless router upon execution of at least someof the instructions by the processor performs authentication to verifyvalidity of the wireless router firmware image.

In some embodiments, the wireless link interface conforms with at leastone 802.11 standard for wireless communications. In some, the wirelessrouter includes a 10/100 Mbps local area network interface card toprovide a data communication connection to a local area network, and thekernel includes instructions which upon execution by the processor atleast partially control operation of the local area network interfacecard. In some embodiments, the kernel includes open source operatingsystem code.

The examples given are merely illustrative. This Summary is not intendedto identify key features or essential features of the claimed subjectmatter, nor is it intended to be used to limit the scope of the claimedsubject matter. Rather, this Summary is provided to introduce—in asimplified form—some concepts that are further described below in theDetailed Description. The innovation is defined with claims, and to theextent this Summary conflicts with the claims, the claims shouldprevail.

DESCRIPTION OF THE DRAWINGS

A more particular description will be given with reference to theattached drawings. These drawings only illustrate selected aspects andthus do not fully determine coverage or scope.

FIG. 1 depicts a schematic diagram of a system and device for processingnetwork content;

FIG. 2A illustrates an exemplary configuration to protect a singledesktop computer;

FIG. 2B illustrates an exemplary configuration to protect a local areanetwork (LAN), which includes multiple desktop computers;

FIG. 3 illustrates an exemplary operating sequence of a system anddevice configured to process email traffic;

FIG. 4 illustrates an exemplary operating sequence of a system anddevice configured to process various web content viewed by a user usingthe user's computer;

FIGS. 5A, 5B, 6A and 6B provide more detailed illustration of aninternal operating sequence of a system and device;

FIGS. 7A and 7B depict alternative schematic diagrams of a wirelessrouter system and device for processing network content, include onewireless router configuration with an Ethernet 10/100 Mbps local areanetwork interface card, and one configuration without that networkinterface card; and

FIG. 8 is a flow chart illustrating steps of some method embodiments forremoter firmware update.

DETAILED DESCRIPTION

Observations on Focus

It is not unusual for a child application to set forth claims which havea different focus than the claims of a parent application. In thepresent situation, provisional application No. 60/653,163 contains 148pages of a disclosure which was incorporated and built upon in theapplication that ultimately issued as U.S. Pat. No. 7,904,518. Thepresent document incorporates and builds upon both those ancestorapplications. Claims of the '518 patent focus in part on filtering emailmessage content, but the underlying applications are not limited to thattopic. The claims presented here are differently focused than the '518patent claims, but an attentive reader will find common subject matterin the three applications. For example, the present document is titled“Wireless Router Remote Firmware Upgrade,” the '163 provisionaldiscusses a Remote Rash Updater utility capable of writing firmware toflash memory, and the '518 patent Abstract states that an “appliance isprovided with an automatic remote updating capability, wherein thesoftware and data used by the appliance can be updated remotely via anetwork.” The '518 patent also teaches that some embodiments of theappliance include functionality of a network hub or router.

Observations on Meaning and Scope

Reference will now be made to exemplary embodiments such as thoseillustrated in the drawings, and specific language will be used hereinto describe the same. But alterations and further modifications of thefeatures illustrated herein, and additional applications of theprinciples illustrated herein, which would occur to one skilled in therelevant art(s) and having possession of this disclosure, should beconsidered within the scope of the claims.

The meaning of terms is clarified in this disclosure, so the claimsshould be read with careful attention to these clarifications. Specificexamples are given, but those of skill in the relevant art(s) willunderstand that other examples may also fall within the meaning of theterms used, and within the scope of one or more claims. Terms do notnecessarily have the same meaning here that they have in general usage,in the usage of a particular industry, in a given reference documentdiscussing others' work, or in a particular dictionary or set ofdictionaries. Reference numerals may be used with various phrasings, tohelp show the breadth of a term. Omission of a reference numeral from agiven piece of text does not necessarily mean that the content of aFigure is not being discussed by the text. The inventors assert andexercise the right to their own lexicography. Terms may be defined,either explicitly or implicitly, here in the Detailed Description and/orelsewhere in the application file.

Reference will be made to the accompanying drawings. The drawings showby way of illustration, and not by way of limitation, specificembodiments and implementations consistent with principles andpossibilities presented herein. The mere fact that the same referencenumber is used in two places in the figures and/or the text does notimply that the referenced item is identical in every respect in eachinstance. For example, appliance 101 shown in FIG. 1 is not necessarilyidentical in every respect with appliance 101 shown in FIG. 2A, or withappliance 101 shown in FIG. 2B, and so on. The various implementationsare described in sufficient detail to enable those skilled in the art topractice the invention and it is to be understood that otherimplementations may be utilized and that structural changes and/orsubstitutions of various elements may be made without departing from thescope and spirit of the claimed invention. The description is,therefore, not to be construed in a limited sense. Additionally, variousembodiments described may be implemented in the form of a softwarerunning on a general purpose computer, in the form of a specializedhardware, or combination of software and hardware, except as otherwiserequired by the claim being considered.

Throughout this document, use of the optional plural “(s)” means thatone or more of the indicated feature is present. For example, the term“firmware change(s)” means “one or more firmware changes” orequivalently “at least one firmware change”.

As used herein, “overwriting” a memory means overwriting at least aportion of the memory. That is, overwriting a memory allows overwritingthe entire memory, but does not require overwriting the entire memory.

As used herein, “updating” and “upgrading” are used interchangeably.

As used herein, a “chunk” of flash memory is the smallest amount ofmemory that is overwritten to perform a single flash memory write. In atypical flash memory, chunk size is 128 Kbytes, but different vendorsmay use different chunk sizes. A flash memory chunk is sometimes calleda “block,” but care is called for because attention to context revealsthat the word “block” is also used in other ways, e.g., in discussingfilesystem data structures.

Remote Rash Updater

In some embodiments, a Remote Rash Updater (RFU) is a utility capable ofwriting to flash memory, a type of non-volatile memory storage, with animage file gathered off a HTTP server. With reference to FIGS. 7A, 7B,and 8 , for example, in some embodiments the RFU 701 is a utilitycapable of writing firmware 702 to flash memory 107 or other firmwarestorage 108. The RFU may be implemented to run with a kernel 703, suchas an open source operating system kernel.

In one embodiment, the RFU 701 is a Linux 2.4 kernel based user-landsoftware running on an ARM based chipset. It is written in ANSI Cprogramming language compiled cleanly with an ARM gcc compiler with the-Wall and -O2 compiler flags. RFU 701 development may be guided byfamiliarity with flash memory code source samples including source codefor a flash kernel driver, and a library implementation that interfaceswith the flash kernel driver. One RFU 701 uses a C library with flashI/O functionality. One RFU binary name is RFUpdater.

In one embodiment, the Linux 2.4 system implements a ROM to RAM remap819 for file system access. Upon boot, the boot loader decompresses 822data held within flash memory and copies 823 it into a RAM based filesystem. After the RFU 701 updates flash memory 107 or other firmwarestorage 108 with an image file, the system 101 will reboot 812 in orderfor the changes to be live. Secure, cross-standard and compactprogramming methodologies are used.

One Updater 701 method includes the following steps, which are exemplaryrather than the sole possible implementation of teaching herein. Beginupdater execution. Calculate kernel 703 and ramdisk flash memory offsetand size. Initialize POST update variables. Issue an HTTP 1.0 POSTrequest on update.akalink.net port 80/TCP. Read header response,continue if new update is available. Read header response, image filesize >100 KB and <3.5 MB. Calculate kernel and ramdisk flash memoryoffsets from image file. Write 815 image file to 128 KB blocks of RAM(write kernel and ramdisk separately). Re-order 817 RAM blocks inreceived order. Authenticate 833—if image file checksum is valid,continue. This is a less than 180 second cycle. Perform overlappingsteps to re-program flash memory starting with kernel followed byramdisk (a kernel-first approach 814): Erase next block chunk of flash,write next block chunk to flash from RAM, free up RAM block chunk.Reboot 812 system.

In some embodiments, a purpose of the remote flash updater 701 is towrite to flash memory 107 or other firmware storage 108 an image theupon invocation, the image the being gathered remotely from a HTTP site.

During a process of downloading the image the off the HTTP server, someembodiments require the image file to be chunked down in 128 KB memoryblocks since the system 101 won't be able to allocate 3.5 MB of memoryin a single allocation. This option is dynamic for tuning purposes.Block re-ordering 817 is done afterwards to validate the image checksum.

Some embodiments utilize already existent flash library functions toachieve the result of re-programming flash memory; they don't requirere-writing a full flash implementation from scratch.

In some embodiments, the image file contains the kernel image and theramdisk image embedded as one. Therefore, byte offsets headers duringthe HTTP session are provided in order for the kernel image and ramdiskimage to be written to the proper flash memory 107 or other firmwarestorage 108 area allocated for theft usage.

During the process of receiving 808 the image 809 file off the HTTPserver and writing the image file to flash memory, some embodimentsperform basic authentication 833 to verify if the image file is valid.

In some embodiments, the maximum size of flash memory an embodiment isutilizing is 4 MB. 256 KB of memory is reserved with another 256 KBmemory of free space, therefore only 3.5 MB is allocatable to flashmemory.

In some embodiments, the kernel image is written to flash memorystarting from 0x10000 to the size of 0x0007FFFF. The ramdisk image iswritten to flash memory starting from 0x90000 to the size of the image.

In some embodiments, the flash library and flash kernel library headerfiles provide information regarding flash memory offsets, instructionsand function. An implementer may study the flash source code providedalong with this document in order to write this software. Along with thesource code, ethloader.c is software that remotely updates flash memoryby passing it a file name, kernel image or ramdisk image, with orwithout specifying length. It could be a good source of reference toutilize as it can broaden understanding and avoid confusion.

In some embodiments, after the updater 701 is executed, it willinitialize all variables regarding kernel and ramdisk memory area beginand end offsets and anything else related to that in order to know whereto write what in what area, sizes of blocks, how many blocks to write,etc. It will then initialize a HTTP POST request 804 to be sent toupdate.akalink.net on port 80 via TCP/IP (of course, other websites willbe used by other vendors). The socket timeout is 5 seconds, and 15seconds for a returned response.

An example of a POST request:

action=updatename=hcubeitem=image

An example of a POST response:

X-Update-Length: 2097152<—Length of imageX-Update-Offset: 668402<—Last byte of Kernel Image from 0X-Update-Cksum: 1808e84cfcbaf71ce1073cc418ff262a<—cksum checksumX-Update-Item: image<—Item requestedImage file data here<—Item requested data

If the X-Update-Item header value is “image” in such embodiments, theembodiment knows it is dealing with the correct item, and will proceed.

Some embodiments will then verify if this image file is recent byverifying if the header X-Update-Cksum is different than the Cksum cksumlocated in a file called “cksum” which holds the contents of the imagecurrent cksum.

If so, processing proceeds to see if 818 the X-Update-Length headervalue is less than 3.5 MB (3670016 bytes) and larger than 100 KB (102400bytes).

If so the embodiment will read and write the image file off the HTTPserver to various 128 KB RAM blocks in two different groups one for thekernel image and one for the ramdisk image, separating them based on theX-Update-Offset header value.

Before the Offset starting from 0 is the kernel image, and after theoffset is the ramdisk image. The X-Update-Offset header value representsthe last byte of the kernel image starting from 0 byte, the rest tillthe last byte represents the ramdisk image.

Some embodiments will re-order 817 the RAM blocks in first receivedpriority and see if 833 the cksum checksum of the total imagecorresponds to the value of X-Update-Cksum.

Some embodiments will begin to re-program flash memory, and will proceedto start writing the kernel byte offset range rather than the ramdiskoffset range afterwards. Kernel image goes first (a kernel-firstapproach 814). This process is on a block level not a byte level forperformance purposes.

In some embodiments, the procedures will erase the next available 128 KBblocks in flash, will write to flash the next 128 KB available blockchunk from RAM, and afterwards will de-allocate the RAM block chunkmemory written and proceed in a cycle until the image file has beenwritten.

Once the embodiment has completed writing the image file to flashmemory, it will reboot 812 the system in order for the image filechanges to go live.

In some embodiments, Online Upgrade Software will destructively 811upgrade the flash 107 on a chunk by chunk basis unless adequate headroomexists to maintain a redundant flash bank to hold the working software.

In some embodiments, a CubeUpdater is a built-in software componentwhose purpose is to perform software updates and check for new updateson a daily basis. The CubeUpdater will use 6 am, 12 am, 6 pm as hoursduring the day to attempt to perform a software update. This is used incase if the internet connectivity is down at 6 am, it will retry atdifferent hours.

When it comes time to perform the software update, it will connect toupdate.spamcube.com on port 80 and issue a HTTP POST with the followingvariables: mac=>00:20:ed:25:34:37. Other websites and addresses will, ofcourse, be used in other implementations.

It will return the following answer if there is an error:

0: Invalid client identification2: No updates available3: Billing information is inactive

If the client billing is not active, the next time the client browses asite, the router redirects 830 the browser to a billing activation page,such as a user profile web page that informs the user of billing statusand invites the user to make payment or other arrangements to activateservice. In some embodiments, an LED status on the router is alsochanged to reflect the billing status and notify the client.

In some embodiments, the router upgrade includes software generally, asopposed to firmware alone. The upgrade software can be stored on a disklocal to the router, e.g., in compressed or archive format such as taror gz format. After extracting the software, setting/checkingpermissions, and applying the upgrade, the router continues (sometimeswithout rebooting) providing services to the user client.

Some embodiments include a software hierarchy, implemented in acollection of file system directories. In a Linux system or otherUNIX-style system, for example, .o object code for the router may bekept in a/boot/modules directory. Configuration files such as .conf andsome .txt files, may be kept in a /usr/local/<router>/conf directory,where <router> is a name representing the router code, e.g., “hcube” or“RFU”. A sysconfig database configuration file may be kept in a/usr/local/<router>/conf directory, for example. User interface .htmlfiles may be kept in a /usr/local/<router>/www/include/tpl/htmldirectory, for example.

A user interface in some embodiments includes pages in a web browser,through which the router receives commands (e.g., check for availableupdates) and notifies the user of status (e.g., billing inactive,upgrade needed, upgrade available, upgrade installed). Familiarmechanisms may be used in the user interface, e.g., HTML forms and formvariables, CGI files, HTML template pages, environment variables,configuration files, and so on. Some embodiments perform a flash updateprocedure on a WEB_CONFIG_FILE to write the configuration file to flashmemory storage.

Some embodiments update a text the containing configuration settings toflash memory via CGI. The CGI the will be executed on a system utilizingflash memory 107 as storage, therefore this functionality is used tokeep updated configuration settings in memory after a system reboot. Insome embodiments, the flash update functionality is already in place, itis being used to update another the called sysconfig. Some embodimentscan use webconfig/flash.c function call kd_updateFlash and setDefault toprovide functionality to update our custom configuration file settingsto flash memory.

In some embodiments, the configuration file settings will simply be atext file with variables separated by a semicolon pointing to a valueseparated by a new line. The configuration file settings is “sample.cnf”modifiable by a define statement. Comments should be ignored.

For example, “SysIPAddress: 192.168.200.1\n” would be a configurationline.

Some embodiments build on familiar mechanisms. For some embodiments, oneof skill may be interested in source provided under names such aswebserver, webconfig, sysconfig.

By way of example, and not limitation, one embodiment includes: at least2 10/100 Mbps Ethernet ports, an ARM based processor of at least 10 MHz,at least 10 MB of memory which can include SDRAM, SRAM, FLASH, and alsoROM, a reset button, a power supply, LEDs, and a printed circuit boardor other motherboard to which the other components aresoldered/attached/connected. The components are housed in a plasticcase. But with regard to hardware, one of skill will understand thatmethods described herein can be used for a wide variety of hardwarecombinations, including variations in memory capacity, processorarchitecture and speed, interface capabilities, and othercharacteristics of computing/networking hardware.

It is to be understood that both the foregoing and the followingdescriptions are exemplary and explanatory only and are not intended tolimit the claimed invention or application thereof in any mannerwhatsoever.

Automatic Remote (Networked) Updating Capability

Additional aspects related to the invention will be set forth hi part hithe description which follows, and in part will be obvious from thedescription, or may be learned by practice of the invention. Aspects ofthe invention may be realized and attained by means of the elements andcombinations of various elements and aspects particularly pointed out hithe following detailed description and the appended claims.

In some embodiments, a methodology provides an integrated plug and playsolution for home networks. An appliance can be used for processing ofweb and email traffic and can be deployed as a stand-alone appliance. Inone implementation, the appliance utilizes a remote service accessed viaa network. The system executes various procedures to handle the networktraffic. In one embodiment, the system is provided with an automaticremote updating capability, wherein the software and data used by thesystem can be updated remotely via a network.

In some embodiments, a method includes connecting a network hardwareappliance to an external network within a home network configuration;including a central processing unit (CPU) on the network hardwareappliance; providing a memory for storing a set of computer-readableinstructions executed by the central processing unit (CPU) on thenetwork hardware appliance; connecting the network hardware appliance toone or more user computers; installing the network hardware appliancebetween the external network and the user's computer; passing allnetwork traffic between the user's computer and the external networkthrough the network hardware appliance; generating a request to retrievefirmware; and receiving firmware. Some embodiments includeauthenticating with a remote system using authentication information.Some include reading from the world wide web using HTTP protocol.

Some embodiments relate to an appliance for processing email and webtraffic. In some embodiments, for example, a network hardware applianceis provided for use with a personal computer of a user, the personalcomputer being connected to a home network of the user. The networkhardware appliance includes a central processing unit (CPU); a firstnetwork interface connected to the personal computer of the user; asecond network interface connected to an external network; and a memorystoring a set of computer-readable instructions. When executed by theCPU the instructions cause the CPU to perform automatic remote firmwareupdates as described herein.

In some embodiments, the personal computer of the user is connected toan external network. The network hardware appliance is connected to thehome network and is positioned between the personal computer of the userand the internet.

In some embodiments, a user request for a web resource is intercepted.The system requests from a target web server the source code for theresource and receives the source code of the requested source from thetarget web server. In some embodiments, an apparatus intercepts contentof a web resource requested by a user. The requested web resource beinglocated on a target web server. The apparatus includes a centralprocessing unit (CPU), a first network interface coupled to the computerof the user, a second network interface coupled to the external networkand a memory storing a set of computer-readable instructions. The CPUoperating under the direction of the stored instructions intercepts auser request for the web resource, requests from the target web serverthe source code for the resource, and receives the source code of therequested source from the target web server.

An embodiment of the methodology provides an integrated plug and playsolution. The appliance can be used for processing of web and emailtraffic and can be deployed as a stand-alone appliance. In anembodiment, the system employs network level analysis and translationand executes various procedures to handle the network traffic. In oneembodiment, the appliance is provided with an automatic remote updatingcapability, wherein the software and data used by the appliance can beupdated remotely via a network.

FIG. 1 depicts a schematic diagram 100 of an exemplary embodiment of anetwork appliance 101 for processing email communications as well asother network content. With reference to FIG. 1 , the appliance mayinclude a data bus 104 or other communication mechanism forcommunicating information across and among various parts of theappliance 101, and a processor (CPU) 105 coupled with bus 104 forprocessing information and performing other computational and controltasks. In one embodiment the processor 105 is an ARM processor withclock speed of at least 10 MHz. Appliance 101 may also include avolatile storage 106, such as a random access memory (RAM) or otherdynamic storage device, coupled to bus 104 for storing variousinformation as well as instructions to be executed by processor 105. Thevolatile storage 106 also may be used for storing temporary variables orother intermediate information during execution of instructions byprocessor 105. In one embodiment, the size of the memory unit 106 is atleast 10 MB. The appliance 101 may further include a read only memory(ROM or EPROM) 107 or other static storage device coupled to bus 104 forstoring static information and instructions for processor 105, such asbasic input-output system (BIOS), as well as various systemconfiguration parameters. A persistent storage device 108, such as amagnetic disk, optical disk, or solid-state flash memory device isprovided and coupled to bus 104 for storing information andinstructions.

The embodiment of the appliance 101 shown in FIG. 1 also includes atleast two communication interfaces, such as network interfaces 113 and114 coupled to the data bus 104. Communication interfaces 113 and 114provide a two-way data communication coupling to a network link 114 thatis connected to the network 115. For example, communication interfaces113 and 114 may be 10/100 Mbps local area network interface cards (LANNIC) to provide a data communication connection to a compatible LAN.Wireless links, such as well-known 802.11a, 802.11b, 802.11g andBluetooth may also be used for network implementation. In any suchimplementation, communication interfaces 113 and 114 send and receiveelectrical, electromagnetic or optical signals that carry digital datastreams representing various types of information.

Network link 114 typically provides data communication through one ormore networks to other network resources. For example, network link 114may provide a connection through network 115 to a host computer 120, orto other network resources (not shown). Thus, the appliance 101 canaccess network resources located anywhere on the Internet 115, such as aremote network storage or web servers. On the other hand, the appliance101 may also be accessed by user computer 121 located anywhere on thecorresponding local area network.

Local network (not shown) and the Internet 115 both use electrical,electromagnetic or optical signals that carry digital data streams. Thesignals sent through the various networks and the signals on networklinks 113 and 114, which carry the digital data to and from appliance101, are exemplary forms of carrier waves transporting the information.

However, carrier waves per se are not claimed. Whenever reference ismade herein to data or instructions, it is understood that these itemsconfigure a computer-readable memory (RAM, ROM, flash, etc.), therebytransforming it to a particular article, as opposed to simply existingon paper, in a person's mind, or as a carrier wave or other transitorysignal on a wire, for example. Unless expressly stated otherwise in aclaim and permitted by applicable law at the relevant time, a claim doesnot cover a signal per se. A memory or other computer-readable storagemedium is presumed to be non-transitory unless expressly statedotherwise.

The appliance 101 can send messages and receive data, including programcode, through the variety of network(s) including any local area networkas well as the Internet 115 by means of network links 114 and 113. Forexample, when the system 101 acts as a network server, it might transmita requested code or data for an application program running on user'scomputer 121 client(s) and/or the host 120 through any local areanetwork (not shown) as well as the Internet 115. Similarly, it mayreceive code or data from other network entities. Likewise, in someembodiments the system 101 includes functionality of a network hub,router, modem, or other network device which has a position in thenetwork configuration adjacent to an illustrated Spam Cube 101 position.

In particular, some embodiments include router functionality. Routerfunctionality in general is familiar. As noted, for example, in U.S.Pat. No. 6,321,267 to Donaldson, in some cases a packet-filtering routerroutes packets from the Internet to an SMTP proxy server via a LAN. Therouter operates at the network layer of the protocol reference modelusing the Internet Protocol version 4 (IPv4). However, with appropriatechanges to the socket programming interface, router functionality alsooperates with other network layer protocols such as Internet Protocolversion 6 (IPv6) or Novell Netware. As noted in US Patent ApplicationPublication No. 2002/0007453 by Nemovicher, some routers switchcommunication traffic between a communication network and a LAN underthe direction and control of a load balancer and fire wall. As noted inUS Patent Application Publication No. 2006/0053293 by Zager et al., insome cases IP addresses are dynamically assigned to most users by DHCPservers at the ISP or a router at the edge of the LAN on which thesender computer resides. As noted in US Patent Application PublicationNo. 2006/0068755 by Shraim et al., a computer and/or any otherappropriate system component may use resources such aspublicly-available domain name server (DNS) data, routing data and/orthe like, to investigate a server suspected of conducting fraudulentactivities. As another example, the routing information in the messageheader may be analyzed to determine whether the message originated fromand/or was routed through a suspect domain, again enhancing thelikelihood that the message is a phish.

With continued attention to FIG. 1 , the received code may be executedby processor 105 as it is received, and/or stored in persistent orvolatile storage devices 108 and 106, respectively, or othernon-volatile storage for later execution. In this manner, the appliance101 may obtain application code updates from remote network resources.

The appliance 101 may also use the network interface 114 to receivevarious code and data updates, which it may use in its operation. Forexample, such data updates may include latest virus definition files.For this purpose, the appliance may perform periodic checks to determinewhether such updates are available. The appliance 101 may also usernetwork interfaces 114 to issue requests to remote network resources,such as remote virus scanning services and to receive the appropriateresponses. Finally, the user may connect to the appliance through, forexample, network interface 113 in order to perform necessaryconfiguration of the appliance.

In one embodiment, one or both of the network interfaces 113 and 114 maybe a wireless network interface operating in accordance with a wirelessnetworking protocol, such as Bluetooth, 802.11a, 802.11b and/or 802.11g.In another embodiment both interfaces 113 and 114 are conventionalwire-based network interfaces.

FIG. 2A illustrates an exemplary home network configuration, wherein theappliance 101 is configured to protect a single desktop computer 201. Inthis exemplary configuration, the appliance 101 is installed between thecable/DSL modern and the user's desktop computer, such that all networktraffic between the user's computer 201 and the outside network 206passes through the appliance. To this end, the user's computer 201 isconnected to one of the aforementioned two network interfaces 113 and114, while the other interface is coupled with the cable/DSL modem 203.The modem 203, in turn is connected via connection 205 with ISP 204,which enables the user's computer to access the internet 206 and remoteservers such as servers 207, 208, 209, 210. In an alternativeembodiment, the functionality of the illustrated Spam Cube 101 and ofthe adjacent cable or DSL modem 203 is combined into a single system101.

FIG. 2B illustrates an exemplary configuration of home network 300,which includes the appliance 101 configured in a manner designed toprotect a local area network (LAN), which includes multiple desktopcomputers 201. In this configuration, the appliance 101 is installedbetween the cable/DSL modem 203 and the network hub/router 301, whichprovides network connectivity to the desktop computers 201.

In alternative embodiments, the functionality and components of theillustrated Spam Cube 101 is combined into a single appliance or system101 with the functionality and components of the adjacent cable or DSLmodern 203, or with the functionality and components of the adjacentNetwork Hub/Router 301, or with the functionality and components of boththe modem 203 and the router 301. In such configurations, the appliance101 can filter all network traffic reaching the computers 201.

The network hub 301 may be wireless network-enabled. In an alternativeembodiment, the network hub 301 may be integrated with the appliance101. The integrated hub may also be either wireless or wired.

The other elements of the networking configuration shown in FIG. 2B,including cable/DSL modem 203, connection 205, and ISP 204, aregenerally equivalent to the corresponding elements of FIG. 2A, describedhereinabove.

FIG. 3 illustrates an exemplary operating sequence of a networkappliance configured to process email traffic. In accordance with theillustrated sequence, email message 302 is sent by an entity located onthe external network (e.g. Internet) 206 to the user's computer 201. Themessage 302 may contain one or more attachments, which may includecertain malware, such as viruses, worms or other threats. In order tofacilitate protection of the user's personal computer from the threatscontained in the email 302, the appliance 101, is arranged to interceptthe email message 302. Upon the interception of the message 302 by theappliance 101, the appliance 101 performs an initial inspection of thereceived email message and its attachment(s) and, if necessary, submitsa service request 304 to the remote antivirus scanning engine 306. Theaforementioned service request may direct the external virus scanningservice to perform a virus check of any attachments to the email message302. In order to enable the requested scanning, the appliance 101 mayinclude the corresponding attachments with the request 304, In oneembodiment, the appliance 101 requests the anti-virus scanning of onlyspecific attachment types. For example, during the initial inspection,the appliance 101 may determine whether the attached file is anexecutable and request remote scanning of the attachment based on theresults of this determination.

After receiving the request 304 from the appliance 101, together withthe relevant attachment email files, the remote scanning system 306performs the necessary processing of the email attachments anddetermines the presence of any threats therein in accordance withwell-known scanning algorithms. The scanning system may utilize aplurality of alternative scanning algorithms. The exact algorithm usedby the system may be selected by the user of the appliance 101 duringthe configuration process. The user's selection may be stored in thestorage devices 106, 107 or 108 of the appliance 101. Existing scanningproducts which may be used by the scanning system 306 include, withoutlimitation, Norton Antivirus and McAfee Security software. The use ofthe remote scanning service 306 enables the system to perform scanningoperations in an on-demand manner without providing the appliance 101with the processing power required to perform the scanning operation. Inaddition, the scanning software executing on servers 306 may be easilyand conveniently updated. The aforementioned two features of the systemconfiguration enable the appliance 101 to be implemented usinginexpensive hardware.

After the completion of the scanning process, the external scanningengine 306 responds to the appliance 101 with response 305 containinginformation on any detected threats. For example, the response 305 mayindicate that one or more of the attachments to the email containviruses. Upon receipt of they response, the appliance 101 neutralizesthe detected threat, by, for example, removing the infected attachment,and re-writes the received email message 302 to include appropriatewarning to the user. The aforesaid warning may be placed either in thesubject line or in the body of the message. The re-written emailcontaining the warning 308 is then forwarded by the appliance 101 to theuser's computer 201. Finally, the appliance 101 performs the update ofits statistics information.

FIG. 4 illustrates an exemplary operating sequence 400 of the networkappliance configured to process various web content viewed by a userusing user's computer. The depicted process is initiated when a userrequests a web resource by inputting at 402 URL 401 into a web browserwindow on user's computer 201. Upon the receipt of the URL information401, the browser sends HTTP request 403 requesting the target webservice (in the example shown in FIG. 4 , the target website is) thewebsite of CNN news service) to provide the resource specified by thereceived URL, The request 403 is intercepted by the appliance 101, whichcontacts the target web server 406 on behalf of the user and sends arequest 404 for the source code of the web resource specified by theuser. In response to the received request, the target server 406 sends areply message 405, accompanied with the full source code of therequested resource. The appliance 101 receives the code furnished by theweb server 406 and initiates a scan of the received source code for anypossible threats, including, for example, any spyware.

During the scan process, the appliance 101 may use a remote scan engine408 to achieve most comprehensive threat detection. To this end, theappliance 101 may send a request 409 to the remote network of scanengines 408 containing the entire source code of the web resource, orany portion thereof. The outside scan engines 408 examine the content ofthe received source code and send reply 407 to the appliance, indicatingwhether any potential threats were detected. Upon the receipt of thereply 407, the appliance 101 sends at 410 a warning message 411 to bedisplayed in the user's browser window, warning the user of the presenceof any potential threats within the requested web resource. In oneembodiment, after the appropriate warning is displayed to the user, theuser is provided with an option to either avoid viewing potentiallyharmful web resource or to proceed with the viewing despite the shownwarning.

FIGS. 5A, 5B, 6A and 6B provide more detailed illustration of theinternal operating sequence of an embodiment of the appliance.Specifically, FIG. 5A depicts the first phase 500 of that exemplaryoperating sequence. The shown operating sequence is executed by the CPU105 shown in FIG. 1 . In order to enable the appliance to execute thedescribed procedures, the appliance may be provided with an operatingsystem, which may be pre-loaded into one or more of the storage devices106, 107 and 108 of FIG. 1 . Exemplary operating systems which may beused to control appliance 101 include Linux, UNIX (example: BSD), orRTOS (example: VxWorks).

The process illustrated in FIG. 5A is automatically initiated when, atstep 502, the appliance 101 accepts a connection from user's computer201 on the outbound port 110, corresponding to TCP/IP protocol, wellknown to persons of skill in the art. Through the establishedconnection, at step 503, the appliance 101 intercepts a requestgenerated by user's email client software to retrieve messagescorresponding to user's email account from the internet service provider(ISP). At step 504, the appliance opens a connection to the destinationIP address corresponding to the email service subsystem of the ISP. Atstep 505, the system receives authenticating information, such asusername and password, corresponding to user's email account with theISP. The system uses the received authentication information toestablish a session with the remote email service and, at step 506,sends to this service a command to scan the user's mailbox for duplicatemessages and, when appropriate, to delete them. At step 507, the systemreceives the “LIST” command from the user's email client and forwards itto the email service system. The aforesaid list command request theemail service to provide the listing of all emails in the user's emailaccount.

The continuation of the first phase 500 of the process shown in FIG. 5Ais illustrated in FIG. 5B. At step 508, the appliance receives from theuser's email client the “RETR” command, which requests the remote emailsubsystem to retrieve one or more email messages in the user's emailaccount. Upon the receipt of this command from the email client, theappliance 101 forwards it to the email server, which, in response,begins a message retrieval process. Prior to retrieving a specificmessage, the appliance 101 first performs a check of the message size.If the size of the message is less than a predetermined threshold value,for example, 200 KB, the system retrieves the entire message, see step510. On the other hand, if the size of the message exceeds the aforesaidthreshold, only a block of the message is retrieved, see step 509. Inone embodiment of the system, the size of the retrieved block is 200 KB.However, other block sizes may be used instead.

Upon the retrieval of the message, the system first checks if the senderof the message identified in the “From” field thereof matches anexisting entry in the blacklist table. This table lists all senders, theemail correspondence from which should be blocked. If the match in theblacklist table is found, the corresponding email message is blocked atstep 521. At step 512, the appliance checks whether the content of themessage, as described by the “Content-Type” field of the message header,may include encrypted attachments. If the message contains onlyunencrypted attachments, the operation proceeds to step 514, whereuponthe system requests the remote HTTP virus scanning server to perform thescanning of the message body for viruses. If the virus is found, thesystem blocks the message at step 521. If, no virus is found or if themessage may contain encrypted attachments, the operation of the systemproceeds to step 513, whereupon the sender of the message, which isidentified in the corresponding “From” record, is compared with entriesin the whitelist table. This table contains a list of sender emailaddresses from which email correspondence should be allowed withoutfurther inspection. If the sender address matches one of the aforesaidwhitelist entries, the email message is allowed at step 520.

On the other hand; if the message sender email address does not matchany entries in the whitelist, the system checks the recipient of theemail message identified in the “To” field of the message header againstentries in the parental control profile. This profile includes emailaddresses of recipients, which should not receive email messages. If thematch is found, the email message is again blocked at step 521, If nomatching entries in the parental control profile exist, the systemproceeds with step 516, whereupon the identity fraud analysis algorithminspects the header of the email message for possible phishing scam. Ifsuch scam is detected, the message is again blocked at step 521.

Upon passing of the phishing scam inspection, the message header patternis analyzed at step 517 for SPAM content. Again, if SPAM is detected,the message is blocked at step 521. If SPAM is not detected in theheader; at step 518, the system checks whether the message headerindicates presence of encrypted email message. The encrypted content isindicated, for example, by presence of “Content-Type:application/x-pkcs7-mime” record in the header of the email. If thecontent is not encrypted, the system inspects the body of the messagefor SPAM content at step 519. If the SPAM is not detected or if theemail body is encrypted, the system accepts the email at step 520.

After the email is rejected at step 521 or accepted at step 520; thesystem performs certain logging and user notification operationsillustrated in FIG. 6A. Specifically, is the email is allowed or denied,the system collects and stores the session logging information at steps628 and 601, respectively. In case of a denial, the appliance at step602 verifies whether identity fraud was detected in the email content.If this was the case, the email is tagged by placing an appropriatemessage, such as “[PHISH]” either in the subject line (step 603) or,alternatively, in the header of the email message (step 607), dependingon the configuration parameters specified by the user. The system mayfurther insert phishing scam alert into the body of the message at step606.

The system then proceeds with the determination of whether a virus wasdetected in the email, see step 608. If the virus was found, theappliance again performs tagging of the email either in the subject lineor in the header, depending on the user's configuration, at steps609-610 and 611-612, respectively. If the user's parameters call forrecipient notification of virus-containing emails, the system disablesthe virus and re-writes the message body inserting an appropriate viruswarning (steps 613 and 614). If the configuration requires sendernotification, the appliance generates an email message to the sender ofthe virus-containing email, which includes a message alerting the senderof the email message of the virus (step 616).

If SPAM was detected in the email message, the email is likewise taggedeither in the subject or the header, at steps 618, 620 and 621-622,respectively. Finally, at step 623, the system inserts a managementcontrol toolbar into the message body.

The continuation of the described operating process is illustrated inFIG. 6B. With reference to this figure, the tagged email with theinserted management toolbar is forwarded to the client at step 624. Theclient terminates the session at step 615 with the QUIT command, whichthe system forwards to the remote email server. Finally, at step 626,the system sends the collected logging information to a remote HTTPserver for storage. The shutdown and session termination is performed atstep 627. The system logs detailed information on the accepted andrejected messages, as well as the detected threats. Upon the request bythe user, the logged information may be displayed in a text or graphicalform.

It should be noted that the present invention is not limited to anyspecific email or web communication protocols. The appliance may beutilized in connection with any known communication protocols,including, without limitation, POP3, SMTP or HTTP.

Finally, it should be understood that processes and techniques describedherein are not inherently related to any particular apparatus and may beimplemented by any suitable combination of components. Further, varioustypes of general purpose devices may be used in accordance with theteachings described herein. It may also prove advantageous to constructspecialized apparatus to perform the method steps described herein. Thepresent invention has been described in relation to particular examples,which are intended in all respects to be illustrative rather thanrestrictive. Those skilled in the art will appreciate that manydifferent combinations of hardware, software, and firmware will besuitable for practicing the present invention. For example, thedescribed software may be implemented in a wide variety of programmingor scripting languages, such as Assembler, C/C++, pert, shell, PHP,ASP.NET, Java, Ruby, AJAX, Rails etc.

Moreover, other implementations of the invention will be apparent tothose skilled in the art from consideration of the specification andpractice of the invention disclosed herein. Various aspects and/orcomponents of the described embodiments may be used singly or in anycombination in the computerized content filtering system. It is intendedthat the specification and examples be considered as exemplary only,with a true scope and spirit of the invention being indicated by thefollowing claims.

Methods

FIG. 8 illustrates some method embodiments, in a flowchart 800. In agiven embodiment zero or more illustrated steps of a method may berepeated. Steps in an embodiment may also be done in a different orderthan the top-to-bottom order that is laid out in FIG. 8 . Steps may beperformed serially, in a partially overlapping manner, or fully inparallel. The order in which a flowchart is traversed to indicate thesteps performed during a method may vary from one performance of themethod to another performance of the method. The flowchart traversalorder may also vary from one method embodiment to another methodembodiment. Steps may also be omitted, combined, renamed, regrouped, orotherwise depart from the illustrated flows, provided that the methodperformed is operable and conforms to at least one claim. Stepsdescribed as being performed by a user may also be performed by anotherperson, or by a machine, on behalf of a user. Another person whoperforms steps on behalf of a user need not have a particular user inmind.

Some embodiments provide a method for upgrading a wireless router. Someinclude the step of containing 801 a firmware 802 version 803, namely, aflash memory in the wireless router 101 containing a first version ofrouter firmware, with the router firmware including instructions to beexecuted by a processor 105 of the wireless router, and the routerfirmware also including data.

Some methods include remotely requesting 804 a firmware update 805,namely, the wireless router sending 806 a request 807 for a firmwareupdate, with the request being sent from the wireless router over anetwork 115 connection toward a server 207.

Some methods include receiving 808 a responsive firmware image 809,namely, the wireless router receiving over the network connection aresponse to the request for a firmware update, with the responseincluding at least a firmware image for a second version of routerfirmware which differs from the first version of router firmware byreason of containing at least one firmware change, a firmware changebeing a difference in firmware data and/or a difference in firmwareinstructions. The firmware image includes a plurality of chunks 810,each chunk having a size which is no greater than a predetermined chunksize.

Some methods include destructively overwriting 811 flash memory chunks,namely, the wireless router destructively overwriting the first versionof router firmware 802 in the flash memory with the second version ofrouter firmware 802. In some, the destructive overwriting proceeds in achunk-wise manner such that prior to being overwritten by all of thechunks the flash memory contains neither a complete copy of the firstversion nor a complete copy of the second version of the routerfirmware. In some embodiments, the wireless router 101 is configured torun whatever version of router firmware is in the router's flash memoryafter the router system 101 is rebooted 812.

Some methods include going live 813 with upgraded firmware 802, byreason of the wireless router rebooting 812 and thereby making thefirmware change(s) go live.

In some embodiments, a wireless router upgrading method includes writing814 the flash memory and then writing 814 a kernel 703 memory, That is,the wireless router destructively overwrites the first version of routerfirmware in the flash memory with the second version of router firmware,and then writes a copy of content of the second version of routerfirmware to a kernel memory in a volatile RAM memory 106 in the wirelessrouter 101 before going live 813 with the upgraded firmware. This is akernel-first approach described above.

In some embodiments, a wireless router upgrading method includes writingboth 815 flash memory and a volatile RAM disk. That is, the wirelessrouter destructively overwrites the first version of router firmware inthe flash memory with the second version of router firmware, and alsowrites a copy of content of the second version of router firmware to aRAM disk in a volatile RAM memory 106 of the router 101.

In some embodiments, the firmware image chunks 810 have at least onepredetermined executable order, namely, an order in which the chunks arearranged in an executable copy of the firmware image, Some routerupgrading methods include receiving 808, 816 firmware chunks 810 in avolatile RAM memory in the wireless router in an order which differsfrom the executable order, and re-ordering 817 the chunks. For example,in some methods the step of destructively overwriting 811 flash memorychunks also arranges 817 chunks in the flash memory in the executableorder.

In some embodiments, the firmware image 702 has a size and the flashmemory has a storage capacity, and the method includes the wirelessrouter checking 818 to see whether the size of the firmware image isless than a predetermined maximum firmware image size. For example, thepredetermined maximum firmware image size can be at least a specifiednumber (e.g., one, two, four, eight) of chunk sizes smaller than theflash memory storage capacity.

In some embodiments, the wireless router remaps 819 a ROM memory address820 in the router to a RAM memory address 821 in the router. This may bedone, for example, to pass control to code at the remapped address. Insome methods, the wireless router decompresses 822 data held within theflash memory in the router and copies 823 the data to a RAM-based filesystem in the router. For example, the router may decompress and copy afirmware image, an operating system kernel, email filtering code,anti-virus definitions, and/or other data.

In some embodiments, the router uses flash memory (in addition to or inplace of a hard disk or remote store, for instance) to preserve userconfiguration through a reboot. Before going live with upgradedfirmware, the wireless router overwrites 824 at least a portion of theflash memory with user-definable configuration settings 825 from a textfile 826. The settings may be copied, for example, into one or moreflash chunks that are not occupied by the firmware image code. Aftergoing live with upgraded firmware, the wireless router overwrites 827the text file with the configuration settings from the flash memory.

In some embodiments, the response received 828 includes an indication829 that a user's billing status is inactive, and the method redirects830 a web browser 831 to a billing activation page 832.

In some embodiments, the firmware image chunks 810 have at least onepredetermined executable order, the step of receiving a responsivefirmware image receives 816 the chunks in the wireless router in anorder which differs from the executable order, and the method re-orders817 the chunks such that the step of destructively overwriting flashmemory chunks arranges chunks in the flash memory in the executableorder, and the method also writes 815 a copy of the chunks to a kernelmemory in the wireless router.

In some embodiments, the router authenticates 833 the firmware image,e.g., by using a server certificate, image checksum, decryption, and/orother familiar authentication tool or technique.

CONCLUSION

Although particular embodiments are expressly illustrated and describedherein as methods or as devices, it will be appreciated that discussionof one type of embodiment also generally extends to other embodimenttypes. For instance, the descriptions of methods in connection with FIG.8 also help describe the operation of devices/systems like thosediscussed in connection with FIGS. 1, 2A, 2B, 3, 4, 7A, and 7B. It doesnot follow that limitations from one embodiment are necessarily readinto another.

Not every item shown in the Figures or discussed in the text need bepresent in every embodiment. Although some possibilities are illustratedhere in text and drawings by specific examples, embodiments may departfrom these examples. For instance, specific features of an example maybe omitted, renamed, grouped differently, repeated, or be a mix offeatures appearing in two or more of the examples. Thus, email filteringis omitted from some embodiments of appliance 101. Functionality shownat one location may also be provided at a different location in someembodiments. Thus, some appliances 101 have a mix of wireless hubfunctionality as well as remote update functionality.

Reference has been made to the figures throughout by reference numerals,Any apparent inconsistencies in the phrasing associated with a givenreference numeral, in the figures or in the text, should be understoodas simply broadening the scope of what is referenced by that numeral.

As used herein, terms such as “a” and “the” are inclusive of one or moreof the indicated item or step. In particular, in the claims a referenceto an item generally means at least one such item is present and areference to a step means at least one instance of the step isperformed.

Headings are for convenience only; information on a given topic may befound outside the section whose heading indicates that topic.

All claims as filed are part of the specification.

While exemplary embodiments have been shown in the drawings anddescribed above, it will be apparent to those of ordinary skill in theart that numerous modifications can be made without departing from theprinciples and concepts set forth in the claims. Although the subjectmatter is described in language specific to structural features and/ormethodological acts, it is to be understood that the subject matterdefined in the appended claims is not necessarily limited to thespecific features or acts described above the claims. It is notnecessary for every means or aspect identified in a given definition orexample to be present or to be utilized in every embodiment. Rather, thespecific features and acts described are disclosed as examples forconsideration when implementing the claims.

All changes which come within the meaning and range of equivalency ofthe claims are to be embraced within their scope to the full extentpermitted by law.

What is claimed is:
 1. A method for upgrading a wireless router, comprising the steps of: (a) containing a firmware version, namely, a flash memory in the wireless router containing a first version of router firmware, the router firmware including instructions to be executed by a processor of the wireless router, the router firmware also including data; (b) remotely requesting a firmware update, namely, a request for a firmware update being sent between the wireless router and a server over a network connection; (c) receiving a firmware update, namely, the wireless router receiving over the network connection a firmware update, the firmware update including at least a firmware image for a second version of router firmware which differs from the first version of router firmware by reason of containing at least one firmware change, a firmware change being a difference in firmware data and/or a difference in firmware instructions, the firmware image including a plurality of chunks, each chunk having a size which is no greater than a predetermined chunk size; (d) destructively overwriting flash memory chunks, namely, the wireless router destructively overwriting the first version of router firmware in the flash memory with the second version of router firmware, and wherein the wireless router is configured to run a version of router firmware that is in the router's flash memory after being rebooted; and (e) going live with upgraded firmware, namely, the wireless router rebooting, thereby making the firmware change(s) go live.
 2. The wireless router upgrading method of claim 1, further comprising writing the flash memory and then writing a kernel memory, namely, the wireless router destructively overwriting the first version of router firmware in the flash memory with the second version of router firmware, and then writing a copy of content of the second version of router firmware to a kernel memory in a volatile RAM memory in the wireless router before going live with upgraded firmware.
 3. The wireless router upgrading method of claim 1, further comprising writing both flash memory and a volatile RAM disk, namely, the wireless router destructively overwriting the first version of router firmware in the flash memory with the second version of router firmware, and also writing a copy of content of the second version of router firmware to a RAM disk in a volatile RAM memory of the router.
 4. The wireless router upgrading method of claim 1, wherein the firmware image chunks have at least one predetermined executable order, namely, an order in which the chunks are arranged in an executable copy of the firmware image, wherein the step of receiving a responsive firmware image receives the chunks in a volatile RAM memory in the wireless router in an order which differs from the executable order, and wherein the method comprises re-ordering the chunks such that the step of destructively overwriting flash memory chunks arranges chunks hi the flash memory in the executable order.
 5. The wireless router upgrading method of claim 1, wherein the firmware image has a size and the flash memory has a storage capacity, and the method further comprises the step of the wireless router checking to see whether the size of the firmware image is less than a predetermined maximum firmware image size, and the predetermined maximum firmware image size is at least two chunk sizes smaller than the flash memory storage capacity.
 6. The wireless router upgrading method of claim 1, further comprising the step of the wireless router remapping a ROM memory address in the router to a RAM memory address hi the router.
 7. The wireless router upgrading method of claim 1, further comprising the step of the wireless router decompressing data held within the flash memory in the router and copying the data to a RAM-based file system in the router.
 8. The wireless router upgrading method of claim 1, further comprising the steps of: before going live with upgraded firmware, the wireless router overwriting at least a portion of the flash memory with user-definable configuration settings from a text file; and after going live with upgraded firmware, the wireless router overwriting the text the with the configuration settings from the flash memory.
 9. The wireless router upgrading method of claim 1, including receiving an indication that a billing status is inactive, and redirecting a web browser to a billing activation page.
 10. The wireless router upgrading method of claim 1, wherein the firmware image chunks have at least one predetermined executable order, namely, an order in which the chunks are arranged in an executable copy of the firmware image, wherein the step of receiving a responsive firmware image receives the chunks in the wireless router in an order which differs from the executable order, and the method comprises re-ordering the chunks such that the step of destructively overwriting flash memory chunks arranges chunks in the flash memory in the executable order, and the method also comprises writing a copy of the chunks to a kernel memory in the wireless router.
 11. A remotely upgradable wireless router, comprising: a processor; a volatile RAM memory in operable communication with the processor and containing a kernel, the kernel including data and including instructions which upon execution by the processor at least partially control operation of the wireless router, the kernel in particular containing a flash memory device driver; a network interface card connectable to a TCP/IP network for two-way data communication of the wireless router with a remote server, the network interface card in operable communication with the volatile RAM memory; a wireless link interface connectable to a wireless network for two-way data communication of the wireless router with a local device, the wireless link interface in operable communication with the volatile RAM memory; a flash memory in operable communication with the processor by use of the flash memory device driver, the flash memory containing a version of wireless router firmware, the wireless router firmware including data and including instructions which upon execution by the processor at least partially control operation of the wireless link interface; the wireless router further characterized in that upon execution of at least some of the instructions by the processor, the wireless router will do the following: receive over the network interface from the remote server a wireless router firmware image, write content of the wireless router firmware image to the flash memory, write content of the wireless router firmware image to the kernel memory after writing the content to the flash memory, and then reboot, thereby passing control to at least some of the wireless router firmware content that was written to the flash memory.
 12. The remotely upgradable wireless router of claim 11, wherein the flash memory has a storage capacity, and the wireless router firmware image includes a plurality of chunks, each chunk having a size which is no greater than a predetermined chunk size and is less than one-eighth the flash memory storage capacity, and wherein the wireless router upon execution of at least some of the instructions by the processor destructively overwrites the version of wireless router firmware in the flash memory in a chunk-wise manner with chunks of the wireless router firmware image.
 13. The remotely upgradable wireless router of claim 11, wherein the wireless router firmware image includes a plurality of chunks which have at least one predetermined executable order, namely, an order in which the chunks are arranged in an executable copy of the wireless router firmware image, and wherein the wireless router upon execution of at least some of the instructions by the processor receives the chunks in the RAM memory in an order which differs from the executable order, and re-orders chunks to arrange the chunks in the flash memory in the executable order.
 14. The remotely upgradable wireless router of claim 11, further comprising a ROM memory address remapped to a RAM memory address in the router.
 15. A system comprising the remotely upgradable wireless router of claim 11 and a text file containing user-defined configuration settings, wherein the flash memory contains a copy of the user-defined configuration settings.
 16. The remotely upgradable wireless router of claim 11, wherein the wireless router firmware image has a size and the flash memory has a storage capacity, the wireless router firmware image includes a plurality of chunks, each chunk has a size which is no greater than a predetermined chunk size and is less than one-eighth the flash memory storage capacity, and the size of the wireless router firmware image is at least two chunk sizes smaller than the flash memory storage capacity.
 17. The remotely upgradable wireless router of claim 11, wherein the wireless router upon execution of at least some of the instructions by the processor performs authentication to verify validity of the wireless router firmware image.
 18. The remotely upgradable wireless router of claim 11, wherein the wireless link interface conforms with at least one 802.11 standard for wireless communications.
 19. The remotely upgradable wireless router of claim 11, further comprising a 10/100 Mbps local area network interface card to provide a data communication connection to a local area network, the kernel including instructions which upon execution by the processor at least partially control operation of the local area network interface card.
 20. The remotely upgradable wireless router of claim 11, wherein the kernel comprises open source operating system code. 